House number normalization for master street address guide (msag) address matching

ABSTRACT

A technique and apparatus to allow a determination of an MSAG-valid address by use of normalized house numbers included in address entries in an MSAG Address data store, to facilitate the simple match of an input civic/postal address against entries in a MSAG data store based on the use of a normalization of the house numbers. The house number normalization allows for an easy lexicographical determination as to whether or not the input civic/postal house number falls with the range of house numbers in the MSAG data store. The inventive process and apparatus pre-stores normalized house number fields in an MSAG address data store, and then normalizes house numbers in a civic/postal address associated with an emergency call. The normalized numbers in the input civic/postal address associated with the emergency call are then lexicographically matched with normalized entries in an MSAG address data store.

This application is a continuation of U.S. patent application Ser.12/232,484, filed on Sep. 18, 2008, which claims priority from U.S.Provisional Application No. 60/960,459, entitled “MSAG Simple Matching aCivic/Postal Address Using Unique Normalized House Number Fields”, toGeldenbott, Hines and Martin, filed Oct. 1, 2007; and also from U.S.Provisional Application No. 60/960,148, entitled “Optimal Selection ofMSAG Address for Valid Civic/Postal Address”, to Geldenbott, filed Sep.18, 2007, the entirety of both of which are expressly incorporatedherein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to long distance carriers, InternetService Providers (ISPs), and information content deliveryservices/providers and long distance carriers. More particularly, itrelates to emergency call systems (e.g., E9-1-1) including wireless andInternet Protocol (IP) based Voice Over Internet Protocol (VoIP)emergency call systems.

2. Background of Related Art

9-1-1 is a phone number widely recognized in North America as anemergency phone number that is used to contact emergency dispatchpersonnel. Enhanced 9-1-1 (E9-1-1) is defined by an emergency call beingselectively routed to an appropriate PSAP, and enhanced information(callback number, name and location) is provided to the PSAP. This isaccomplished through the use of the ANI. The ANI may be the real phonenumber of the caller (in landline E911) or a pseudo-ANI called an ESRK(in cellular E911) or ESQK (in VoIP E911). Regardless of the networktype, a 9-1-1 service becomes E-9-1-1 when automatic numberidentification and automatic location information related to the call isprovided to the 9-1-1 operator at the PSAP.

This identifier allows the PSAP to retrieve location information such asthe Master Street Address Guide (MSAG) valid address of the E9-1-1caller's Civic/Postal Address. The Master Street Address Guide (MSAG)represents a community provided local address master guide that permitsthe most accurate dispatch of emergency personnel to a “correctaddress.” The “correct address” originates as the civic/postal addressof an E9-1-1 emergency caller over a wireless and/or Internet Protocol(IP) based Voice Over Internet Protocol (VoIP) emergency call system.The civic/postal address represents the caller's location at the timewhen the emergency call is placed. This civic/postal address needs to beassociated with an appropriate corresponding MSAG address, which in mostcases is required by the public safety answering point (PSAP).

A Public Service Answering Point (PSAP) is a dispatch office thatreceives 9-1-1 calls from the public. A PSAP may be a local, fire orpolice department, an ambulance service or a regional office coveringall services. As used herein, the term “PSAP” refers to either a publicsafety access point (PSAP), or to an Emergency Call Center (ECC), a VoIPterm.

Distributed emergency call systems in telecommunications are in generalvery complex computing systems. Emergency calls that originate from aVoIP network use well proven routing paradigms already used for cellular911 calls, or for traditional landline 911 calls. These paradigmsusually work well, because VoIP customers can usually be grouped intotwo categories: a mobile VoIP caller that resembles a cellular user, anda stationary VoIP user resembling landline usage.

Traditional landline systems use pre-provisioned, generally staticsubscriber addresses, where the landline automatic locationidentification (ALI) provisioning process insures a match to a masterstreet address guide (MSAG) record, which contains an emergency servicenumber (ESN) used to route emergency calls to a PSAP.

But determination of the location of a mobile device proves much, muchmore challenging. To determine location of a mobile device, someconventional cellular systems use separate triangulation technologies(or any of a number of other techniques) to find a latitude & longitudeof an emergency caller. These systems then use a geographic informationsystem (GIS) system to query for a pre-defined region (e.g., a PSAPpolygon) that contains this location.

Of course, errors may occur in conventional systems when determining thelocation of a mobile user. But even though it's very possible that thesequeried PSAP polygons can lead to a different (i.e., wrong) neighboringPSAP than an equivalent address provisioned in a landline ALI, thisdiscrepancy is conventionally accepted by PSAPs because the locationitself is likely to be imprecise due to measurement errors—sometimes thelocation is off by hundreds of feet.

Conventional VoIP systems use proprietary technologies, usually based onGIS polygons, or based on pre-provisioning of the caller in thetraditional landline ALI long before the need for an emergency call.

Thus, traditional landline paradigms provide the most accurate locationfor its static users, but require the caller's address to bepre-provisioned into a landline automatic location identifier (ALI).This pre-provisioning (often referred to as service order interface(SOI) loading) usually takes a few days between the caller notifyingtheir service provider of their address change, and this change beingreflected in the landline ALI. But during this window a 911 call mightbe made, and if so it would be routed using the “old” data still in thelandline ALI. Even the fastest possible conventional landline ALIprovisioning takes at least several hours.

Existing solutions include the NENA VoIP architecture for enhanced 9-1-1services standard NENA 08-001. However, such conventional technologiesare too complicated and not always practical. Moreover, conventionalsystems are disadvantageous because they are unable to handle theembedded geographic location to precisely route the caller to thecorrect PSAP using the “just-in-time” paradigm.

A “simple match” to find an MSAG-valid address refers to a simplelexicographic comparison of an input civic/postal address against theentries in an MSAG address store to find a positive match. The presentinventors have appreciated that house numbers prove to be particularlyhard to compare as in many cases house numbers contain digits andalpha-numeric characters in any random order. Given this fact, two housenumbers that are not character-for-character identical may refer to thesame house number as determined by a human observer.

Compounding this issue is the fact that otherwise conventional MSAG datastored in an otherwise conventional MSAG address data store is alwaysgiven as range data including a low and high house number, e.g.,“100-2000 Elm Street.” So with this, a simple match must successfullydetermine if a given input civic/postal house number falls within astored MSAG address house number range.

The MSAG-valid address is required by most PSAPs, as it represents acommunity provided local address that allows accurate dispatch ofemergency personnel to the correct address. But a challenge remains toprovide a MSAG-valid address, particularly with respect to a real-timeVoice Over Internet Protocol (VoIP) emergency call.

SUMMARY OF THE INVENTION

In accordance with the principles of the present invention, a masterstreet address guide (MSAG) address data store comprises a plurality ofaddress entries, each entry comprising an address, a normalized lowhouse number field, and a normalized high house number field.

In accordance with another aspect of the invention, a method of matchinga civic/postal address associated with an emergency call with a masterstreet address guide (MSAG) address table comprises normalizing thehouse number of an input civic/postal address associated with anemergency call to comprise an alphanumeric string having a fixed numberof characters. The normalized house number is provided for matchingagainst normalized entries in the master street address guide (MSAG). AMSAG address is selected from the MSAG address table in which thenormalized house number falls lexicographically between the normalizedlow house number and the normalized high house number of the MSAGaddress.

In yet other aspects of the invention, a process of normalizing a housenumber portion of a civic/postal address and MSAG address range for usewith an address database. Normalizing consists of converting eachnon-alphanumeric character in the house number portion to a spacecharacter. Consecutive space characters in the house number portion arereplaced with a single space character. Leading and trailing spaces inthe house number portion are removed. Each group of consecutive digitsare located and padded with leading characters such that each digitsgroup is of a fixed common length.

Normalization of the house number does not convert a house number to avalid house number, rather it converts house numbers to a standardizedform for the purpose of lexicographical comparison.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the present invention will become apparent tothose skilled in the art from the following description with referenceto the drawings, in which:

FIG. 1 shows an exemplary MSAG data store including an MSAG addresstable including a plurality of entries, in accordance with theprinciples of the present invention.

FIG. 2 shows an exemplary process of normalizing house numbers from acivic/postal address and from MSAG addresses for use with respect to anMSAG Address data store, in accordance with the principles of thepresent invention.

FIG. 3 shows normalizing an input house number, then determined if theinput house number is “normalized-between” a given entry's low housenumber and a high house number, in accordance with the principles of thepresent invention.

FIG. 4 shows sample house number normalizations, in accordance with theprinciples of the present invention.

FIG. 5 shows sample normalized house numbers inserted into respectiveentries of an exemplary MSAG address table in an MSAG Address datastore, in accordance with the principles of the present invention.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The present invention provides a technique and apparatus to allow adetermination of an MSAG-valid address by use of normalized housenumbers included in address entries in an MSAG Address data store. Inparticular, it provides a unique method to facilitate the simple matchof an input civic/postal address against entries in a MSAG data storebased on the use of a normalization of the house numbers. The housenumber normalization allows for a simple lexicographic determination asto whether or not the input civic/postal house number falls with therange of house numbers in the MSAG data store.

The present invention provides a very high matching rate of a masterstreet address guide (MSAG) address using unique house numbernormalization on both: (1) an input civic/postal address; and (2) theMSAG addresses stored in an MSAG address data store. The inventiveprocess and apparatus normalizes house number fields in an MSAG addressdata store in advance of matching, and then normalizes input housenumbers from a civic/postal address associated with an emergency call.The normalized numbers in the input civic/postal address associated withthe emergency call are then lexicographically matched with normalizedentries in an MSAG address data store to successfully perform simpleMSAG matching on an input civic/postal address.

An otherwise conventional MSAG address data store contains addressranges. According to the invention, the low and high MSAG house numbersare normalized and stored based on house number normalization rulesestablished by the present invention. The normalized house numbersstored in the MSAG address data store may be normalized before firstbeing stored in the MSAG address data store; or may be converted andrestored in a new format accommodating the normalized form of the housenumbers.

According to the invention, an input civic/postal address house numberassociated with an emergency call is converted using the same housenumber normalization as that used on the entries already stored in theMSAG address data store, and then lexicographically matched against theaddress range in the MSAG address data store. The conversion may beaccomplished in a module associated with presenting a match inquiry tothe MSAG address data store, or within the mobile device making therelevant emergency call, or anywhere there between. In this way, becauseof the normalization of the input house number, the input civic/postaladdress has a high probability to successfully match against the MSAGaddress data store, in accordance with the principles of the presentinvention.

With this invention, normalized house numbers are used on both the inputcivic/postal house number, as well as on the MSAG address low and highhouse numbers in the MSAG data store. The normalized civic/postal inputhouse number is then lexicographically compared against the normalizedMSAG address low and high house numbers in the data store.

While the disclosed embodiments utilize an MSAG address matchingtechnique referred to as a Simple Match for which an MSAG Address tablesuffices, in practice the MSAG data store may contain more than just theMSAG address table suitable to support the relevant match techniqueused.

FIG. 1 shows an exemplary MSAG data store 100 including an MSAG addresstable 101 including a plurality of entries, in accordance with theprinciples of the present invention.

In particular, as shown in FIG. 1, a suitable database, referred toherein as an MSAG data store 100, includes an MSAG Address table 101.The MSAG Address table 101 includes multiple entries, each of whichincludes an associated data field for each of an MSAGAddress_ID 102, anMSAG Address 104, an MSAG_LOW_HOUSE_NUM_NORM 106, and anMSAG_HIGH_HOUSE_NUM_NORM 108.

Thus, each entry in the MSAG Address table 101 is uniquely identified bythe MSAGAdress_ID 102 data.

Though the MSAG Address 104 field is shown in the disclosed embodimentsas one field for reasons of simplicity, the MSAG Address 104 field ingeneral preferably comprises several fields capable of documenting astreet address.

According to the invention, each entry in the MSAG Address table 101also comprises a NORMALIZED low house number MSAG_LOW_HOUSE_NUM_NORM106, and a NORMALIZED high house number MSAG_HIGH_HOUSE_NUM_NORM 108.

FIG. 2 shows an exemplary process of normalizing house numbers extractedfrom a civic/postal address, and for use of normalizing MSAG Addressdata store house numbers, in accordance with the principles of thepresent invention. In particular, FIG. 2 shows exemplary rules 400 tonormalize a house number.

In step 420, a house number is input.

In step 401, the input house number is converted to a common case, e.g.,all to upper case. Of course, normalization might instead normalize allhouse numbers to lower case within the scope of the present invention.

In step 402, each non-alphanumeric character (e.g. punctuation) isconverted to a space character.

In step 403, consecutive space characters are replaced with a singlespace character.

In step 404, leading spaces and trailing spaces are removed.

In step 405, every group of consecutive digits (not whitespace, notalphanumeric) are located.

In step 406, each located group of digits is padded with leading zerossuch that each digits group is exactly a common length, e.g., apreferred 10 digits in the disclosed embodiments.

FIG. 3 shows normalizing an input civic/postal house number, thendetermined if the input house number is “normalized-between” a givenentry's low house number and a high house number, in accordance with theprinciples of the present invention.

In particular, as shown in FIG. 3, in step 501 an input civic/postaladdress house number is normalized using the rules shown in FIG. 2.

In step 502, the input civic/postal address including the now-normalizedhouse number is compared to entries in the relevant MSAG Address datastore to search for MSAG addresses where the input house number is“normalized-between” those MSAG address records. If the normalized inputhouse number is lexicographically between the normalized low andnormalized high house numbers of an MSAG address record, then the inputhouse number is referred to as “normalized-between” the low and highhouse numbers of that MSAG record. Even though the originalnon-normalized input civic/postal house number might not belexicographically between the original non-normalized high and low housenumber on that MSAG record, this ‘normalized-between’ step findslegitimate MSAG records that match the input civic/postal house number.

FIG. 4 and FIG. 5 illustrate the normalization process and determiningwhether or not a house number is “normalized-between” a low and highhouse number. First, FIG. 4 showing sample house number normalizations200 will be described in accordance with the principles of the presentinvention.

In particular, as shown in FIG. 4, the input low and high house numbersare normalized preferably before being stored in the MSAG Address table.The first example 202 in FIG. 4 shows how house numbers consisting onlyof digits are normalized using the rules enumerated above. In thisexample, the civic/postal low and high (i.e., range) house numbers“1100” and “2200” are normalized into “0000001100” and “0000002200”,respectively.

Similarly, the second example 204 shows house numbers starting with analpha-numeric character (e.g., “N”). In the second example 204, thecivic/postal low and high house numbers “N0340” and “N0900” arenormalized into “N0000000340” and “N0000000900”, respectively.

The third example 206 depicts an example of normalization of housenumbers with a trailing alpha-numeric character. In this example,original civic/postal low and high house numbers “10G” and “40G” arenormalized into “0000000010G” and “0000000040G”, respectively.

More complex examples would work in the same fashion following theenumerated rules above, in accordance with the principles of the presentinvention.

FIG. 5 shows sample normalized house numbers inserted into respectiveentries of an exemplary MSAG address table 300 in an MSAG Address datastore, in accordance with the principles of the present invention.

In particular, as shown in FIG. 5, the MSAG address table 300 includessample civic/postal addresses and house number ranges (i.e., as definedby both low and high house numbers), as shown in the examples 202, 204and 206 in FIG. 4.

It is important to point out that the “MSAG Address” parameter shown inFIG. 5 still contains the original UN-normalized house number, whereasthe parameters or fields described as “MSAG_LOW_HOUSE_NUMBER_NORM” and“MSAG_HIGH_HOUSE_NUMBER_NORM” contain the corresponding normalizedvalues. With that, the normalized house numbers for the “MSAG Address”field in the first civic/postal address entry 302 is “1100-2200 2ih AVENE Seattle Wash. 98115”, with the address range defined by thenormalized values of “0000001100” and “0000002200”, respectively.

Similarly, the “MSAG Address” field in the second civic/postal addressentry 304 contains the original civic/postal address: “N0340-N0900 NE55th St Seattle Wash. 98115”, from which the normalized address isdetermined and stored as a low and high house number, e.g.,“N0000000340” and “N0000000900”.

Finally, in the third and last example civic/postal address entry 306,the “MSAG Address” field contains the original the original civic/postaladdress: “10G-40G NE Park Rd Seattle Wash. 98115”, from which thenormalized address is determined and stored as a low and high housenumber, e.g., “000000001OG” and “0000000040G”.

Therefore, taking the very last example, for the sample civic/postalinput address of “0035G NE Park Rd Seattle Wash. 98115” a simple matchwould be found with civic/postal address 306, in accordance with theprinciples of the present invention, since the normalized form of“0035G” is “0000000035G”, which lexicographically falls between theNormalized range of “000000001OG” and “0000000040G” of that civic/postaladdress entry 306.

Accordingly, using modules put in place to normalize not only the housenumber range in all entries put into an MSAG Address table, but also asuitable normalization module to perform the same normalization on aninput civic/postal address to be matched to the entries in the MSAGAddress table, the present invention guarantees that a givencivic/postal address with a non-trivial house number can be simplymatched against an MSAG address in a MSAG Address data store.

The present invention has particular applicability with location basedserver vendors.

While the invention has been described with reference to the exemplaryembodiments thereof, those skilled in the art will be able to makevarious modifications to the described embodiments of the inventionwithout departing from the true spirit and scope of the invention.

What is claimed is:
 1. A method of directing an emergency call to anemergency terminal responsible for a civic/postal address received withthe emergency call, comprising: obtaining a plurality of USPS standardformat civic/postal address ranges for build into a physical MSAGdatabase; converting an upper limit and a lower limit to each of saidplurality of USPS standard format civic/postal address ranges to anon-USPS standard format; storing said non-USPS standard formatcivic/postal address ranges into said physical MSAG database; receivingan emergency call from a mobile device together with an associated USPSstandard format civic/postal address; converting said associated USPSstandard format civic/postal address into said non-UPSP standard format,wherein said non-UPSP standard format comprises: converting eachnon-alphanumeric character in a street number portion of said USPSstandard format civic/postal address to instead comprise a spacecharacter, replacing consecutive space characters in said street numberportion of said USPS standard format civic/postal address with a singlespace character, removing a leading space and a trailing space in saidstreet number portion of said USPS standard format civic/postal address,and padding each group of consecutive digits in said USPS standardformat civic/postal address with at least one leading character suchthat a resultant street number portion of said non-USPS standard formatcivic/postal address is of a fixed common length; lexicographicallymatching said converted, non-USPS standard format civic/postal addressto a non-USPS standard format address range entry pre-stored in saidphysical MSAG database; and directing said emergency call from saidmobile device to a proper physical public safety answering point (PSAP)terminal responsible for said USPS standard format civic/postal addressbased on said lexicographically matched, converted, non-USPS standardformat civic/postal address.